home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-05 / pkd10.zip / 3C503.NOT < prev    next >
Text File  |  1989-07-29  |  6KB  |  132 lines

  1. README.503
  2. 27 July 89
  3. Bob Clements, K1BC
  4. [Updated: 27 July 89 for thick/thin Ethernet choice.]
  5.  
  6. This is the README file that goes with the 3C503 device driver,
  7. 3C503.ASM and 3C503.COM.
  8.  
  9. I wanted to include this file for two reasons:
  10.    1) to give credit where credit is due, and
  11.    2) to say something about this implementation's details.
  12.  
  13. CREDIT WHERE CREDIT IS DUE:
  14.  
  15. The ancestry of this driver is as follows.  The effort was inspired
  16. by Phil Karn's TCP/IP implementation, NET.EXE.  Phil included a
  17. built-in driver for the 3C501 in early versions of NET, up to around
  18. version 871225.30 or so.  
  19.  
  20. I wrote a driver (in C) for the WD8003E which I released in
  21. version 871225.25.EW.  I based this on technical information which
  22. my dealer, Ken Hahn of Micros Unlimited in Woburn MA (a 3-Com
  23. network distributor), was able to get from Western Digital after
  24. some effort.  Credit to Ken and to Western Digital.
  25.  
  26. Shortly after that, Phil saw the need to support more devices without
  27. modifying NET.EXE and he decided to do it by way of the "Packet
  28. Driver" specification publicly promoted by FTP Software of 
  29. Cambridge MA, to whom we owe due credit, too.
  30.  
  31. Russ Nelson at clarkson.edu began implementing and collecting
  32. drivers written to that specification, including a derivative of
  33. Phil's 3C501 driver.  Russ wrote the outer levels of the driver
  34. to meet the FTP Software spec.  Credit to Russ for that and for
  35. the job of collecting other drivers to go with it.
  36.  
  37. I rewrote the built-in C version of the WD8003E driver in 
  38. assembler, fitting it into Russ's structure (as a TSR), 
  39. and released it back to Russ for inclusion in his collection.
  40.  
  41. I wanted to write a version for the 3-Com 3C503 because the 3C501
  42. was continually rumored to be becoming obsolete.  Further, since
  43. it uses the same National DS8390 controller chip as the WD8003E,
  44. I figured it couldn't be TOO different.  Ken and I had been unable
  45. to get programming info for the 3C503 through sales channels or
  46. usenet.  I lamented this fact publicly in early December on usenet.
  47. 3-Com saw the note and immediately provided the necessary info
  48. to me.  They sent me a pre-publication draft of the 3C503's
  49. technical manual and some sample code for a different environment.
  50. Credit to 3-Com in the persons of Jack Moses and Eric Siegel.
  51.  
  52. After a delay due to vacation (K1BC/KH6), winter lethargy and
  53. work schedules, I finally got around to writing the driver in
  54. February 1989.  Sure enough, it wasn't TOO different from
  55. the WD8003E driver.  But see the next section.
  56.  
  57. To all the above named persons, "Thank you".
  58.  
  59.  
  60. DETAILS ABOUT THIS IMPLEMENTATION:
  61.  
  62. The 3C503 is rather versatile.  It allows you to move packets to/from
  63. the card in three ways:  1) By a shared memory buffer;  2) By using
  64. a DMA channel of the PC bus;  3) by I/O instructions per byte or word.
  65. As it comes from the factory, the card has the shared memory jumper
  66. set to "disabled".  This probably prevents phone calls from people
  67. who have address conflicts with their video cards or disk bootstraps.
  68. 3-Com's software includes code to handle all three cases, depending
  69. on the rest of the configuration.
  70.  
  71. I chose to implement ONLY method 1 above for this initial version
  72. of the driver.  Not only is this the fastest transfer method but
  73. it is the method used for the WD8003E driver that I did before.
  74. So I had less work to do.  You MUST set the shared memory to one of
  75. its four possible enabled addresses.  Pick one that doesn't conflict
  76. with your other hardware.  The segment numbers available are:
  77. c800, cc00, d800 and dc00.  The driver can read your selection
  78. from the card, so you don't have to tell it.
  79.  
  80. The 3C503 has jumpers for the above memory addresses and for the I/O
  81. port addresses.  It occupies a block of 16 addresses at one of a
  82. number of jumperable bases.  The default is 300.  You can change
  83. it if you have to.  Supply the actual address as an argument
  84. when you start the driver.
  85.  
  86. The 3C503 interrupt level is programmable.  No jumpers.  Only
  87. levels 2,3,4 and 5 are supported by the hardware.  Tell the driver
  88. what level you want as an argument when you start the driver.
  89. The default level is two.
  90.  
  91. The card has both a thin-net (coax) connector and a thick-net
  92. (external transceiver) connector.  The selection for which 
  93. connection to use is done by software.  No jumpers.  In the first
  94. version of this driver, I failed to provide a way to select
  95. which connection to use, and I got a lot of email about that.
  96. Now, you select which you want by a flag on the command line
  97. after the I/O port address.  A zero means to use the external,
  98. thick-net, connector.  A non-zero number means to use the coax
  99. connector for thin-net.  The default is to use thin-net, which
  100. was the only choice on the old driver.
  101.  
  102. I start the driver on my system with the following line:
  103.     C:>  3c503 0x7e 2 0x300 1
  104. which means "Install on software interrupt 7E (for NET.EXE to use),
  105. use interrupt level 2, find the board at ports 300-30F, and
  106. use the thin-net coax connector".
  107.  
  108.  
  109. There are differences between the way WD's and 3-Com's software 
  110. handle the DS8390.  I changed some of them over to 3-Com's way
  111. for this driver and left some as I had them in the WD driver.
  112. So far, they seem to be working OK.  For one thing, they treat
  113. the "boundary" register differently.  Details available on request.
  114.  
  115. 3-Com also includes a lot of garbled-packet detection in their
  116. driver, based on their experience of failures of the DS8390
  117. under heavy load.  They describe some pretty bizarre things.
  118. I have not included that logic in this driver, since the IP and
  119. TCP checksums should save you in the applications I am
  120. writing for.
  121.  
  122. So my point is that this driver is not as complete an implementation
  123. as the one 3-Com provides for their network systems.  I take the
  124. blame for these compromises.
  125.  
  126. Note added July 1989:
  127. This driver now supports the set_rcv_mode function of the packet
  128. driver spec, but does not yet support set/get_multicast_list.
  129.  
  130. Bob Clements,  K1BC,  clements@bbn.com,  rcc@k1bc.lex.ma.us
  131.  
  132.